UML, vserver, jail and others

The standard chroot restricts a running process to a subdirectory within the host's filesystem. To the process, it sees the directory as the root (/) of its filesystems. It can only access files within the chroot'ed environment. It's fairly trivial to break out of a normal chroot or do other nasty things, especially as userID 0 (root).

FreeBSD's jails are more secure than chroot, because they also provide some restrictions on certain administrative actions, such as mounting and unmounting filesystems, no access to the routing tables or raw sockets, no modifying kernel parameters and sysctl, etc. There's still only one "host" kernel, and even though you might be root inside your jail, you still can't do the things you would expect…

The vserver project (these are all great efforts, btw) tries to go one step further. Rather than patch the kernel here and there, it uses security contexts, with hooks into certain "kernel" functionality. Each vserver gets it's own security context. Some/most of the same limitations apply to vserver as with FreeBSD jails, but in a more sane/controlled fashion. A vserver essentially is trying to mimic what a real kernel does.

Shared kernel approaches don't pre-allocated resources to each environment. Some also require custom user-space tools inside the virtual environment – so that you can't see other processes running that don't belong to your environment. Also, there's no true "booting/rebooting" of a virtual server. They might hack some init scripts, but with UML you can literally COPY a filesystem off a physical machine, and run it inside UML with no modification.

Here is an overview on UML:

~~http://user-mode-linux.sourceforge.net/ … 2/img2.jpg">http://user-mode-linux.sourceforge.net/slides/wvu2002/img2.jpg" />

img src: http://user-mode-linux.sourceforge.net/ … 2/img2.jpg">http://user-mode-linux.sourceforge.net/slides/wvu2002/img2.jpg

UML IS a kernel, so you've got all the functionality of a real kernel inside an UML virtual server. Routing tables, interfaces, devices, you name it. Anything that isn't hardware-specific, you have access to. And those things that are hardware-specific, UML provides drivers for (like hda/ubd devices and network interface).

There is some overhead involved. Tasks which make syscalls inside UML have overhead, however user-space inside UML runs nearly or at full speed.

I've also noticed the tendency for shared-kernel virtual server providers to pack 100s of virtual servers on machines. Sounds like shared hosting to me. Since we don't over commit the machines, there can only be HOSTRAM/UMLRAM number of VS on one host. For example, 2048 MB of RAM on the host means no more than 32 "64M Servers" on the host. I'd rather share the host with 30 other people than 100s…

Generally UML is closer to a "real" physical Linux machine than any of the other technologies can provide.

-Chris~~

Wow, impressive answer.

So let's see if I got it right:

jail / vserver * Shared kernel among all VDS.

• Can't recompile kernel.

• Less overhead for the host, thus allowing more VDS per machine.

• No memory restrictions.

• No CPU restrictions.

• Can't have your own firewall (?)

• ping and postfix won't work (at least with jail).
  UML * Each VDS has its own kernel.

• It's possible to recompile the kernel, but your host will have to install it for you.

• More overhead; less VDS per machine.

• Memory restrictions; the machine you are placed in won't suffer performance-wise even if you have a big servlet or DB.

• No CPU restrictions.

• You can have your own firewall.

• Almost all software works. Does anybody know any program that won't work under UML?

@Werpon:

UML * Each VDS has its own kernel.

• It's possible to recompile the kernel, but your host will have to install it for you.

Note that Chris has stated in the past (and for very good reasons), that user-compiled UML kernels will not be permitted, i.e., even if you do compile your own UML kernel, he will not install it for your Linode. This is because a user-compiled UML kernel cannot be trusted to not screw up the host system, either deliberately or accidentally.

> Does anybody know any program that won't work under UML?

The only programs that don't work under UML are those that use direct access to the hardware. There are very, very few such programs, and all are irrelevent in UML Linux. Examples include hwclock (used to set the BIOS clock, unecessary on a Linode which gets its system time from the host system which is kept accurate by ntpd), and some scsi probing tools.

Without exception, every useful Linux program can be run under UML Linux on your Linode.